IBIS Macromodel Task Group Meeting date: 16 April 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that he had one question that might ultimately be better suited for the Interconnect Task Group. With respect to Interconnect Models (BIRD189), is the value of Number_of_Terminals always N+1 for a File_TS model (where N is the number of ports in the Touchstone file), even if there are unused terminals? The answer is yes. Number_of_Terminals is always N+1 for a File_TS model. If there are no unused terminals, then Number_of_Terminals will be followed by N+1 terminal lines (rows). If there are unused terminals, then Number_of_Terminals is followed by fewer than N+1 terminal lines (rows), and the Unused_port_termination parameter tells the EDA tool how to terminate any unused terminals during simulation. ------------- Review of ARs: - Arpad to send draft_1 of BIRD197.3 to the ATM list. - Done. - Mike L. and Bob to produce a revised draft response to the BIRD198 authors. - In progress. Reviewed below. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 09 meeting. Mike L. moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: BIRD197.3 draft 2 (DC_Offset) Arpad had sent BIRD197.3 draft 2 along with the ATM meeting agenda. It was the same as draft 1 emailed last week, except the "Illegal before" version was changed from 7.0 to X.x. Bob noted that the BIRD draft used "single ended" but the rest of the spec uses "single-ended". Arpad replaced all instances of "single ended" with "single-ended", and the resulting version is what was posted to the ATM archives as BIRD197.3 draft 2. Fangyi noted the question he had posted to the ATM list in response to draft 1. He asked about the following sentence in the BIRD: The waveform output of the Rx AMI_GetWave shall be adjusted so that the EDA tool can add DC_Offset to get the voltage of the waveform at the slicer (aka latch, decision point) of the single-ended port. He said this was ambiguous, and he posed the following question to illustrate his problem with the sentence: If the actual waveform at the latch were centered about zero, should the model return a waveform centered at -DC_Offset so that the EDA tool would then add DC_Offset to get the proper zero centered waveform? Walter said that sentence was intended to say that if the EDA tool wanted to take the output of Rx GetWave() and adjust it so that it could be compared with what would be observed on a single-ended scope in the lab, then it should add DC_Offset to the waveform returned by Rx GetWave(). Radek said the issue was that the DC_Offset, as it was then defined, applied to the input waveform to Rx GetWave(), but there is no guarantee that offset will be the same for the output of Rx GetWave(). Fangyi said the first thing an Rx might do with the input waveform is go through a comparator. The output of the comparator would be zero centered, and the rest of the Rx process, including at the latch, would be centered at zero. In that scenario the Rx GetWave() output (the latch) will center at zero. Arpad and Ambrish noted that we could address this by changing DC_Offset from an In to an InOut, as Fangyi had proposed in his original email to ATM. Then the Rx model could return the modified DC_Offset that applies to the output waveform. Arpad asked if each GetWave() call could return a different value. Fangyi said the model should only return the modified value from Init(). Arpad asked if the authors were willing to incorporate this change. Ambrish said he would work on it. Walter said that he would not want to be a part of this rewrite, as he considered it unnecessary. Response to JEITA authors of BIRD198: Mike L. noted that he and Bob had reviewed earlier drafts and meeting minutes. Their goal was to provide a brief first email explaining ATM's interpretation of the BIRD and forming the basis of a conversation with the authors. Randy had noted via email response that the current draft retained an earlier statement about addressing the same modeling issue using BIRD189. Mike removed it. Mike reviewed the draft. The intro section explaining our interpretation of the BIRD was similar to Walter's original draft. Subsequent sections noted that clarification might be required for defining the interaction between this BIRD198 and [Pin Mapping], [Interconnect Model], or the absence of either. Radek asked if [Package Model] could be used to define the connection points for the BIRD198 model. Mike said he and Bob had considered it, but did not see any way for [Package Model] to declare what the rails would be. Arpad noted that he thought the draft should propose email discussion to start, potentially followed by having one ATM meeting at a special time to facilitate phone conversation with the authors. Mike incorporated the change. Mike said he would send out this draft 6 to the meeting attendees. - Mike L.: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Ambrish to work on BIRD197.3 draft3 to address Fangyi's comments. AR: Mike L. to send draft6 of the BIRD198 reply to meeting attendees. ------------- Next meeting: 23 April 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives